Система прав в инфосистемах

Система привилегий или прав всегда и везде неразрывно связана с системой и пользователями и направлена на поддержания порядка и постоянства данных. В многопользовательских инфосистемах наличие привилегий становится необходимым, когда ставятся под вопрос доверие и безопасность системы, либо хочется разграничить специализацию работников для повышения эффективности.

Права в сложных системах могут включать такие понятия:

• Пользователи (Вася, Петя)
  • Рефлексивность пользователя - он может сам себя удалить/заблокировать?
  • Вес=Карма=Рейтинг пользователя и автоматическая зависимость от этого его принадлежности группе или роли
• Ресурсы и содержание (Картинки, Статьи, Списки), доступ к которым должен быть как-то ограничен
  • Транзактивность - если пользователь начал изменять ресурс, то только он может продолжить ну а если не продолжил то всё останется как было (commit/rollback)
• Права (Actions=Rights=Permissions) - элементарные действия пользователя над ресурсами, как правила по принципу CRUD (изменять/удалять/добавлять), но могут быть и особые (делегировать, отобрать, подтвердить, пригласить)
• Доступ (Realm) - способ аутидентификации и политики прав для конкретных групп и пользователей (login-password, сертификат, биометрические данные, IP подсеть)
• Группы пользователей нужны что-бы быстро придать пользователю заготовленные привилегии. Например полицейские, депутаты, военные выделяются в обществе своими возможностями
• Отдел (Department) - часть компании/организации, часто соответсвует группам пользователей
• Роли (Roles) пользователей - часто путается с группами. На самом деле это синоним сгруппированных прав, по принципу ответственности одного человека в своём отделе. Например, детектив в полиции, медик в военном отряде, спикер в парламенте
• Иерархичность и наследование - если группы или ресурсы имеют иерархичную структуру, то права могут распространяться на нижние слои. Например наследование в монархии, наследование имущества, прав в файловой системе. Наследование может выделено как отдельное право (assign)
• Юридическая ответственность за те или иные ресурсы (claimer / disclaimer)

---

Чёрный и белый список

Если рассматривать права в очень общем смысле, то к примеру в государстве права регулируются по принципу разрешено всё что не запрещено, при этом все запреты оформились в законодательные (уголовные, административные и проч) акты.

В то же время в жёстких и критических системах, когда безопасность становится критичным фактором, системы порой работают по противоположному принципу, запрещая по умолчанию всё и разрешая в единичном порядке.

К примеру военные системы по умолчанию дают каждому права человека Венской конвенции, а в дальнейшем единичные права устанавливаются каждому солдату в зависимости от ранга и должности. 

Таким образом, в зависимости от типа системы, можно выделить

• финансовые и военные системы, где права жёстко закреплены за ролью человека
• рабочие инфосистемы, где права зависят от размера и действий организации
• публичные инфосистемы, где права имеют малую иерархию и как правило разделяются кардинальным образом

Файловая система *никсов

Администраторам должны быть знакомы права устанавливаемые на папки и файлы. Право на использование содержания зависит от группы пользователя (user/group/others), которые находятся в /usr/passwd. Пользователи управляются коммандами useradd, userdel, usermod

Действия, которое он хочет совершить кодируются в восьмеричной (octet) системе исчисления

права сущности	File	Folder
4 = read	чтение файла	список и чтение файлов в папке
2 = write	+изменение файла	+ добавление, изменение, удаление файлов в папке
1 = execute	+ исполнение файла	+ войти в каталог

В итоге для каждого ресурса сохраняются права доступа суммированием и полные права всем = 777

Соотвественно если бы строили систему привилегий по-другому, мы могли бы добавить число прав, число групп, число типов сущностей и всё стало бы значительно сложнее.

Немного абстракций

Теперь вопрос - как в публичных инфосистемах делать систему привилегий? Несомненно клиент как администратор хочет много чего контролировать и как можно эффективней, что-бы не просматривать тысячи однотипных действий, и пользователей.

Права я определяю как действия которые пользователь или группа может совершить над объектами системы. Получается как минимум трёхмерное дискретное пространство. Из-за многомерности, управление ими визуально на плоскости становится сложным с уймой таблиц и checkbox'ов.

По умолчанию в моей системе всё запрещено. Это значит что на каждый ряд таблицы прав приходится разрешение. Вторая особенность - я не стал использовать наследование привилегий. От этого больше возникает проблем и непонимания чем реальной пользы.